Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to new relations format and show edits #420

Merged
merged 9 commits into from
Feb 10, 2021
Merged

Conversation

deepbluev7
Copy link
Member

@deepbluev7 deepbluev7 commented Jan 27, 2021

fixes #402
fixes #134

Currently still incomplete, as there is no indication, that a message was edited.

@deepbluev7 deepbluev7 marked this pull request as draft January 27, 2021 01:43
@deepbluev7 deepbluev7 changed the title Switch to new relations format Switch to new relations format and support edits Jan 28, 2021
@deepbluev7 deepbluev7 changed the title Switch to new relations format and support edits Switch to new relations format and show edits Jan 28, 2021
Does not fix the read status yet, for that we need to compare read
receipts for all events after the last visible event.
// Height of child, plus margins, plus border
implicitHeight: replyPreview.height + 10
implicitHeight: (room && room.reply ? replyPreview.height : closeEditButton.height) + 10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think room && is probably superfluous here? Since the popup is only visible if 'room' is defined, I'm thinking the height doesn't really matter much.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't do the room &&, you get null warnings. It's stupid, but sadly necessary. It's just in the condition to prevent the null warning, apart from this the conditional sets this to reply height or edit height, depending o. if this has a reply or not.

anchors.topMargin: 10
anchors.top: parent.top
//height: 16
text: qsTr("Abort edit")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 'Abort edit' an official phrase from somewhere in the spec? Otherwise, I'd probably use 'Cancel edit' instead. 'Abort' has a sort of negative connotation associated with it.

ImageButton {
id: editButton

visible: (Settings.buttonsInTimeline && model.isEditable) || model.isEdited
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading this correctly, you're overloading this button to be for messages that are already edited as well as for messages that can be edited. If this is the case, it seems like it could be confusing to users. Also, what happens if someone tries to edit the same message twice? the button will say 'Edited' when the user may want to edit again and it may lead them to think they cannot edit the message again despite a button being there that allows them to edit in other scenarios.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I don't really have a good idea on how to solve that. So I just left it like that for now and will later move the edit button into a dedicated action button bar, that shows on hover, while only status icons like read, edited and timestamp are shown by default?

lmdb::dbi_put(
txn, relationsDb, lmdb::val(relates_to), event_id);
auto relations = mtx::accessors::relations(e);
if (!relations.relations.empty()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new code looks much nicer IMO =D

});
mtx::responses::utils::parse_room_account_data_events(j, events);
if (events.size() == 1)
return events.front();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens when there's more than one event? Seems like we ignore it. But shouldn't we still return the most recent one anyway? Or otherwise somehow handle all of the events?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually an ugly hack yo reuse the parser for a list of events to parse a single event. Which is why the event is inserted into a json array at first. One day we should clean that up everywhere in our code :D

@@ -66,7 +66,8 @@ class EventStore : public QObject
// relatedFetched event
mtx::events::collections::TimelineEvents *get(std::string_view id,
std::string_view related_to,
bool decrypt = true);
bool decrypt = true,
bool resolve_edits = true);
// always returns a proper event as long as the idx is valid
mtx::events::collections::TimelineEvents *get(int idx, bool decrypt = true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this function need to have the resolve_edits changes incorporated as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, imo. This always resolves the edits, the other function just alloes side stepping that, to prevent loops as wel es show the edit history in the future.

@@ -518,6 +560,8 @@ InputBar::showPreview(const QMimeData &source, QString path, const QStringList &
[this](const QByteArray data, const QString &mime, const QString &fn) {
setUploading(true);

setText("");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if you want to send text with your upload!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't support that yet. When we do that, it will need more fundamental changes :3

@deepbluev7 deepbluev7 marked this pull request as ready for review February 10, 2021 03:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Render edited messages Support editing messages
2 participants